Multi-core processors and/or multi-threaded instruction execution pipelines within processing cores have caused software programmers to develop multi-threaded software programs. Multi-threaded software is naturally complex because of the different processes that concurrently execute. However, multi-threaded software is additionally difficult to debug because of an aspect of “non-determinism” in the manner of its execution. Specifically, a multi-threaded software program may execute differently across two different run-times even if the program starts from an identical input state.
For these reasons “logging” is used to record certain critical junctures in a multi-threaded software program's execution. Processors are presently designed with logging circuits that observe the execution of a processor's software and record certain critical events that the circuits have been designed to detect. If the software program crashes, the log record is analyzed to study the execution of the program leading up to the crash.
Hardware Transactional Memory (HTM) will soon be used as the cornerstone of many transactional memory (TM) systems. Unfortunately, performing logging and other profiling techniques on HTM systems poses new challenges because prior software-only profiling techniques have only been shown to be acceptable for software-only TM (STM) systems. Because hardware transactions execute an order of magnitude or more faster than software transactions, prior approaches that incurred roughly 10% overhead in software transactions will incur 100% or more overhead for hardware transactions. The profiling community generally agrees that anything over a 10% overhead in profiling data gathering is likely to introduce a probe effect that will change the contention signature of a multi-threaded program, which seems to indicate that these prior techniques are unlikely to be sufficient for HTMs.